The Builderly API is organised around REST. It has predictable resource-oriented URLs, accepts JSON request bodies, returns JSON responses and uses standard HTTP response codes, authentication and verbs.
Every Builderly site answers at its own address, so the base URL is the site's. Add ?ionic=true to receive JSON from endpoints that also render pages.
This reference is generated from the running server - 1163 endpoints in 59 subjects - so it always matches what is deployed.
http://www.allsport.bg
/api-reference/llms.txt /api-reference/llms-full.txt /api-reference/openapi.json /api-reference/pages.md
Everything here reads as plain text too. llms.txt lists every subject and endpoint with a link to its Markdown; llms-full.txt is the whole reference in one file; each subject is Markdown at its own address with .md added (or ask any page with Accept: text/markdown); openapi.json describes every endpoint for tools and function calling. Calls go to the site's own address with its token.
The API uses bearer tokens. A site admin creates one: sign in to the Builderly admin, open Developers > API reference and press Generate token. Send it with every request that needs one. Keep tokens secret - they act as the account they belong to.
Public endpoints need no token. For anything else, ask the user for one - you cannot create it yourself, and never ask for their password. You can send them this message as it is:
To work with your site through its API, I need an API token from you: 1. Sign in to your Builderly admin: https://admin.max-media.io 2. Open Developers > API reference (or go straight to https://admin.max-media.io/tabs/site-builder/api-docs). 3. Press "Generate token", copy the token and paste it here. The token acts as you, so only share it in this chat. You can cancel it at any time by signing out of all devices.
Use the token as Authorization: Bearer <token> with ?ionic=true, against the site's own address. It acts as the user: say what you will change and wait for their yes before creating, changing or deleting anything, and never repeat the token back.
Bearer token of a site admin (Authorization: Bearer <token>).
Bearer token of a signed-in user of the site.
Works without a token; a user token personalises the answer.
A signed-in user whose plan grants access to the item.
Pages limited to some users check the token when one is sent.
Called by a provider; verified by its signature.
Needs a reCAPTCHA token from the site form.
Internal - called by the platform itself.
curl 'http://www.allsport.bg/users/me?ionic=true' \ -H 'Authorization: Bearer <TOKEN>'
The API answers with standard HTTP status codes: 2xx it worked, 4xx the request needs changing, 5xx the server failed. Each endpoint lists the codes it can answer with.
It worked. The answer is the object or list asked for.
The object was created. Some endpoints send it back; others send an empty body.
The work was started and finishes in the background - for example a video being processed ({ "status": "processing" }). Check back on the object.
It worked, and there is nothing to send back - for example after removing a staff member.
The address changed; follow the Location header.
The request was refused as sent: a required field is missing, a value has the wrong type or fails validation. The body says what - often as plain text.
No token, or one that is invalid or signed out. Without ?ionic=true, some endpoints answer this with the HTML login page instead of JSON.
The content needs a subscription: the user has no price plan that unlocks it.
The token is valid but may not do this - the record belongs to someone else, or the user is not an admin. AI builder endpoints also answer 403 when the account is out of credits.
No object with that ID or URL slug, or no such endpoint.
It clashes with the current state: the item is already being processed, a version is already applied, or an AI plan or preview is no longer available.
It existed but is no longer there - for example a comment already deleted on the social network.
A rule the request must meet is not met - for example push notifications of the same type at least 48 hours apart.
An account confirmation or password reset link was used with an email that does not match it.
The domain is not a Builderly site. Call the site's own address.
The request was understood but could not be done - for example the AI could not read the website it was asked to clone. The message says what to try instead.
Slow down: the site's request limit was reached, an AI chat already has a request running, or the hourly limit of AI search answers is used up. Wait and retry.
Something failed on the server. Retrying later may work; if it keeps failing, the request may be one the endpoint does not handle.
A service the request depends on failed - for example the address a redirect forwards to.
Used by the lead form when an order is below its minimum value, not only for outages: read the message.
Errors do not share one shape: depending on the endpoint the body is plain text, { "error": "..." }, { "message": "..." } or empty. Rely on the status code, and show the body to the user as the reason.
200 OK 201 Created 202 Accepted 204 No Content 301 Moved Permanently 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 409 Conflict 410 Gone 412 Precondition Failed 418 I'm a teapot 421 Misdirected Request 422 Unprocessable Content 429 Too Many Requests 500 Internal Server Error 502 Bad Gateway 503 Service Unavailable